1 Social Modeling for Requirements Engineering : An Introduction

Information technology can be used in innumerable ways and has great potential for improving people's lives. Yet, designing systems that truly meet people's needs remains a considerable challenge. Every day we encounter systems that do not do what we want. Many software projects continue to fail at alarming rates. Much of this challenge is attributed to the di‰culty of pinning down system requirements—e¤ective ways to determine what people want when they initially conceive of the need for a software system. This book o¤ers a new way of approaching the requirements challenge. The central premise is that to arrive at system requirements, that is, to conceive what system to build, one should examine and understand the relationships among social actors. A system aims to improve the relationship that some actors have with other actors. Rather than focusing on the behavioral properties of software, as in a mechanistic system, we should raise the level of abstraction and ask how the system will advance the relationships that some actors have in relation to other actors. This perspective leads to a rather di¤erent approach to requirements modeling and analysis , one that is based on describing and analyzing social relationships. We are then led to ask how we model and analyze the social world in order to lead to better system requirements. What concepts should be the basis for such modeling? What questions should the models help answer, and how can they lead us to systematically explore alternatives and analyze the consequences of our choices? Traditionally, the task of the requirements analyst is to collect requirements statements from stakeholders: the customer and representatives of users. These statements say what the system should do (functionality) and at what levels of quality (nonfunctional properties such as performance, reliability, extensibility, usability, and costs). For large systems, there can be a large number of such statements coming from many stakeholders. The analyst aims to ensure that these statements are consistent (i.e., they do not contradict each other), complete (i.e., they fully reflect what the stakeholders are expecting from the system), and unambiguous (i.e., su‰ciently precise so that they will not be misinterpreted by the developers).